<table class="configuration table table-bordered">
    <thead>
        <tr>
            <th class="text-left" style="width: 20%">Key</th>
            <th class="text-left" style="width: 15%">Default</th>
            <th class="text-left" style="width: 10%">Type</th>
            <th class="text-left" style="width: 55%">Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><h5>pulsar.source.allowKeySharedOutOfOrderDelivery</h5></td>
            <td style="word-wrap: break-word;">false</td>
            <td>Boolean</td>
            <td>If enabled, it will relax the ordering requirement, allowing the broker to send out-of-order messages in case of failures. This will make it faster for new consumers to join without being stalled by an existing slow consumer.<br />In this case, a single consumer will still receive all the keys, but they may be coming in different orders.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.autoCommitCursorInterval</h5></td>
            <td style="word-wrap: break-word;">5000</td>
            <td>Long</td>
            <td>This option is used only when the user disables the checkpoint and uses Exclusive or Failover subscription. We would automatically commit the cursor using the given period (in ms).</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.enableAutoAcknowledgeMessage</h5></td>
            <td style="word-wrap: break-word;">false</td>
            <td>Boolean</td>
            <td>Flink commits the consuming position with pulsar transactions on checkpoint. However, if you have disabled the Flink checkpoint or disabled transaction for your Pulsar cluster, ensure that you have set this option to <code class="highlighter-rouge">true</code>.<br />The source would use pulsar client's internal mechanism and commit cursor in a given interval.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.enableMetrics</h5></td>
            <td style="word-wrap: break-word;">true</td>
            <td>Boolean</td>
            <td>The metrics from Pulsar Consumer are only exposed if you enable this option.You should set the <code class="highlighter-rouge">pulsar.client.statsIntervalSeconds</code> to a positive value if you enable this option.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.enableSchemaEvolution</h5></td>
            <td style="word-wrap: break-word;">false</td>
            <td>Boolean</td>
            <td>If you enable this option and use <code class="highlighter-rouge">PulsarSourceBuilder.setDeserializationSchema(Schema)</code>, we would consume and deserialize the message by using Pulsar's <code class="highlighter-rouge">Schema</code> interface with extra schema evolution check.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.fetchOneMessageTime</h5></td>
            <td style="word-wrap: break-word;">(none)</td>
            <td>Integer</td>
            <td>The time (in ms) for fetching one message from Pulsar. If time exceed and no message returned from Pulsar. We would consider there is no record at the current topic partition and stop fetching until next switch.<br />It's not configured by default. We will use the remaining time in <code class="highlighter-rouge">pulsar.source.maxFetchTime</code> by default, which may cause a long wait in small message rates. Add this option in source builder avoiding waiting too long.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.maxFetchRecords</h5></td>
            <td style="word-wrap: break-word;">100</td>
            <td>Integer</td>
            <td>The maximum number of records to fetch to wait when polling. A longer time increases throughput but also latency. A fetch batch might be finished earlier because of <code class="highlighter-rouge">pulsar.source.maxFetchTime</code>.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.maxFetchTime</h5></td>
            <td style="word-wrap: break-word;">10000</td>
            <td>Long</td>
            <td>The maximum time (in ms) to wait when fetching records. A longer time increases throughput but also latency. A fetch batch might be finished earlier because of <code class="highlighter-rouge">pulsar.source.maxFetchRecords</code>.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.partitionDiscoveryIntervalMs</h5></td>
            <td style="word-wrap: break-word;">300000</td>
            <td>Long</td>
            <td>The interval (in ms) for the Pulsar source to discover the new partitions. A non-positive value disables the partition discovery.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.resetSubscriptionCursor</h5></td>
            <td style="word-wrap: break-word;">false</td>
            <td>Boolean</td>
            <td>The <code class="highlighter-rouge">StartCursor</code> in connector is used to create the initial subscription. Enable this option will reset the start cursor in subscription by using <code class="highlighter-rouge">StartCursor</code> everytime you start the application without the checkpoint.</td>
        </tr>
        <tr>
            <td><h5>pulsar.source.verifyInitialOffsets</h5></td>
            <td style="word-wrap: break-word;">WARN_ON_MISMATCH</td>
            <td><p>Enum</p></td>
            <td>Upon (re)starting the source, check whether the expected message can be read. If failure is enabled, the application fails. Otherwise, it logs a warning. A possible solution is to adjust the retention settings in Pulsar or ignoring the check result.<br /><br />Possible values:<ul><li>"FAIL_ON_MISMATCH": Fail the consuming from Pulsar when we don't find the related cursor.</li><li>"WARN_ON_MISMATCH": Print a warn message and start consuming from the valid offset.</li></ul></td>
        </tr>
    </tbody>
</table>
